從數小時到 15 分鐘：AWS DevOps Agent 如何破解澳洲聯邦銀行的網路身份管理難題
-
DIGITIMES
/
台北
- 2025-12-29 00:00:00
澳洲聯邦銀行 (Commonwealth Bank of Australia) 是澳洲最大的金融服務機構之一，服務超過 17,000,000 名客戶。其雲端基礎團隊 (Cloud Foundations group) 管理著超過 1,700 個 AWS 帳戶，為數千名工程師提供集中式雲端運維服務。在這樣龐大且複雜的雲端環境中，當網路和身份管理系統出現問題時，即便是經驗豐富的 DevOps 工程師也常常需要花費數小時才能找到根本原因。然而，當該團隊在建置下一代內部雲端平台時，他們刻意複製了一個複雜的網路與身份管理問題來測試
AWS DevOps Agent——結果這個 AI 代理在不到 15 分鐘內就精準定位了根因。這不僅僅是速度上的突破，更代表著企業運維模式從「被動救火」邁向「主動預防」的關鍵轉變。
當銀行級系統遇上「多小時根因追蹤」困境
澳洲聯邦銀行的雲端基礎團隊面對的挑戰，是現代分散式系統運維人員的共同痛點：當應用程式出現故障時，問題的根源往往隱藏在錯綜複雜的微服務、雲端依賴項以及分散在多個工具中的遙測數據裡。對於管理超過 1,700 個 AWS 帳戶的團隊而言，這個挑戰被放大了數千倍。
在傳統的故障排查流程中，工程師必須手動切換多個監控工具——從
Amazon CloudWatch 查看系統日誌、到 Dynatrace 或 Datadog 分析效能指標、再到 New Relic 追蹤應用程式行為。每個工具都有各自的介面和數據格式，工程師需要在腦海中「拼湊」這些片段化的資訊，才能逐步縮小問題範圍。當問題涉及網路配置和身份管理系統的交互作用時，這個過程變得更加艱難——因為這類問題往往沒有明顯的錯誤訊息，而是表現為「權限正確但就是無法連線」或「配置看起來沒問題但服務異常」的模糊症狀。
對資深 DevOps 工程師來說，這類問題通常需要數小時的深入調查：先檢查網路層的路由表和安全群組規則，再檢查 IAM 政策和服務角色權限，接著驗證跨帳戶存取的信任關係，最後還要排查可能的 DNS 解析或憑證問題。每一步都需要仔細分析大量日誌和配置文件，任何一個環節的疏漏都可能讓調查陷入死胡同。
更棘手的是，當系統規模擴大到數千個 AWS 帳戶時，問題的複雜度呈指數級增長。單一配置變更可能影響數十個相互依賴的服務，而這些依賴關係往往沒有完整的文件記錄。工程師需要依賴經驗和直覺來推測「這個問題可能是哪裡出錯」，然後逐一驗證假設——這是一個耗時且容易出錯的過程。
澳洲聯邦銀行的雲端基礎團隊深知這個痛點。當他們在建置下一代內部雲端平台時，決定用一個真實且複雜的網路與身份管理問題來測試
AWS DevOps Agent 的能力。他們刻意複製了一個在生產環境中曾經困擾團隊數小時的問題場景，想看看這個 AI 代理是否真的能像 AWS 宣稱的那樣「像經驗豐富的 DevOps 工程師一樣思考和行動」。結果令人驚艷：AWS DevOps Agent 在不到 15 分鐘內就找到了根本原因。
AWS DevOps Agent 的「15 分鐘根因定位」是如何實現的？
AWS DevOps Agent 之所以能在 15 分鐘內完成資深工程師需要數小時才能完成的根因分析，關鍵在於它從設計之初就被打造成「隨時待命的虛擬運維團隊成員」。當應用程式出現故障時，
AWS DevOps Agent 會立即啟動響應流程，並運用對應用程式架構和組件關係的深入理解來精準定位問題根源。
首先，
AWS DevOps Agent 會自動學習你的資源及其關係，涵蓋從可觀測性工具 (如
Amazon CloudWatch、Dynatrace、Datadog、New Relic、Splunk) 到 runbooks、代碼庫，以及持續整合與持續交付 (CI/CD) 管道的完整生態系統。這種全方位的資源映射能力，使得 AWS DevOps Agent 能夠理解應用程式的完整脈絡——不僅知道每個組件的當前狀態，更清楚它們之間的依賴關係和互動模式。
當澳洲聯邦銀行的測試場景中出現網路和身份管理問題時，
AWS DevOps Agent 並沒有像人類工程師那樣逐一檢查各種可能的原因。相反地，它運用機器學習演算法同時分析來自多個來源的數據：網路流量日誌、IAM 政策變更記錄、安全群組規則、服務角色權限、以及相關服務的錯誤訊息。透過關聯遙測數據、代碼變更和部署歷史，
AWS DevOps Agent 能夠快速建立一個「問題假設樹」，並根據數據證據逐步排除不相關的分支，最終收斂到真正的根本原因。
更重要的是，
AWS DevOps Agent 不會被人類工程師常見的認知偏差所影響。人類在面對複雜問題時，往往會優先檢查「上次出問題的地方」或「最近改動過的配置」，這種經驗法則在大多數情況下有效，但也可能導致遺漏真正的根因。
AWS DevOps Agent 則能夠客觀地評估所有可能性，並根據數據相關性而非經驗直覺來優先排查順序。
在澳洲聯邦銀行的案例中，這個網路和身份管理問題涉及多層配置的交互作用——單獨檢查每一層都看不出異常，但當它們組合在一起時就會產生意外的阻斷效應。這種問題對人類工程師來說特別棘手，因為需要同時在腦海中建構多個配置層的完整圖像。但對
AWS DevOps Agent 而言，它可以輕鬆處理數百個變數的交互作用，並透過圖論演算法找出導致故障的關鍵路徑。
此外，
AWS DevOps Agent 還能夠存取和理解非結構化數據——包括 runbooks 中的故障排查指南、代碼註解中的已知問題說明、以及過去事件報告中的經驗總結。這使得它能夠像一位「閱讀過所有內部文件」的資深工程師一樣，快速定位到相關的歷史案例和解決方案，從而加速根因分析的過程。
Amazon 內部驗證：數千次升級中的 86% 根因識別率
AWS DevOps Agent 的能力並非只是在實驗室環境中的理論驗證，而是經過 Amazon 內部大規模實戰檢驗的成熟技術。根據 AWS 官方數據，在 Amazon 內部處理的數千次系統升級事件中，
AWS DevOps Agent 達到了超過 86% 的根因識別準確率——這意味著在絕大多數情況下，它都能正確指出問題的真正來源，而不是給出模糊或誤導性的建議。
要理解 86% 這個數字的含義，我們需要認識到 Amazon 內部系統的複雜度遠超一般企業。作為全球最大的雲端服務供應商和電商平台，Amazon 每天都在進行大量的系統升級、功能部署和基礎設施調整。這些變更涉及數以萬計的微服務、跨越多個地理區域的分散式系統、以及各種新舊技術堆疊的混合環境。在這樣的複雜度下，任何一次升級都可能觸發連鎖反應，導致看似無關的服務出現異常。
傳統的故障排查方法在這種規模下往往力不從心。當一個問題涉及 50 個微服務、100 個 API 端點和 1,000 個配置參數時，人工分析所有可能的組合幾乎是不可能的任務。即使是經驗最豐富的 DevOps 團隊，也只能依賴監控告警和日誌搜尋來縮小範圍，但這個過程既耗時又容易遺漏關鍵線索。
AWS DevOps Agent 之所以能在 Amazon 內部達到 86% 的準確率，是因為它結合了多種先進技術：首先，它使用機器學習模型來識別異常模式，這些模型是基於 Amazon 多年累積的運維數據訓練而成，能夠識別出人類可能忽略的微妙關聯。其次，它運用圖神經網路 (Graph Neural Network) 來建模複雜的服務依賴關係，從而在龐大的系統拓撲中快速定位故障傳播路徑。第三，它整合了時間序列分析技術，能夠將系統變更事件與效能指標變化精確關聯，找出因果關係而非僅是時間上的巧合。
更重要的是，這 86% 的準確率是在「零人工標註」的條件下達成的。
AWS DevOps Agent 不需要工程師事先標記哪些事件是真正的故障根因，而是透過觀察系統行為和修復措施的效果來自我學習和改進。這種無監督學習能力使得
AWS DevOps Agent 能夠持續適應新的系統架構和故障模式，而不會因為技術堆疊的演進而失去效用。
對於澳洲聯邦銀行這樣的大型金融機構而言，86% 的準確率意味著什麼？假設該銀行每月遇到 100 次需要調查的系統異常，使用
AWS DevOps Agent 後，有 86 次能夠在 15 分鐘內獲得準確的根因診斷，而不是讓工程師花費數小時甚至數天來追查問題。這不僅大幅縮短了平均修復時間 (MTTR)，更釋放了工程團隊的時間和精力，讓他們能夠專注於更有價值的創新工作，而非陷入無止境的故障排查循環。
從「全員救火」到「主動預防」的運維轉型
AWS DevOps Agent 帶來的價值不僅止於快速定位根因，更重要的是它能夠幫助組織從「反應式運維」轉型為「主動式改進」。在傳統的運維模式中，團隊的大部分時間都花在應對突發事件上——當系統出現問題時，所有人立刻放下手邊工作投入救火，等問題解決後再回到原本的任務。這種模式雖然能夠快速恢復服務，但卻無法從根本上減少故障發生的頻率。
AWS DevOps Agent 透過分析歷史事件中的模式，能夠提供針對性的改進建議，幫助團隊在問題發生之前就加以預防。它會檢視過去數週、數月甚至數年的事件記錄，識別出哪些類型的問題重複出現、哪些系統組件最容易失效、以及哪些配置變更最常引發故障。基於這些洞察，
AWS DevOps Agent 會產生可執行的改進建議，涵蓋四個關鍵領域。
第一個領域是可觀測性增強。
AWS DevOps Agent 可能會建議在某些關鍵服務中增加更細緻的日誌記錄、設置新的監控指標、或調整告警閾值以減少誤報。例如，如果它發現某類問題總是在特定的記憶體使用模式下出現，就會建議添加相關的自訂指標，讓團隊能夠在問題惡化之前及早發現並介入。
第二個領域是基礎設施優化。透過分析系統效能數據和資源使用模式，
AWS DevOps Agent 能夠識別出過度配置或配置不足的資源，建議調整執行個體類型、自動擴展政策或資料庫配置。這些優化不僅能提升系統穩定性，還能降低運營成本——例如，將某些工作負載遷移到更適合的執行個體類型，既能提高效能又能減少費用。
第三個領域是部署管道增強。許多故障是在部署過程中引入的，因此改進 CI/CD 管道的品質把關機制至關重要。
AWS DevOps Agent 可能會建議增加自動化測試覆蓋率、實施更嚴格的程式碼審查規則、或採用藍綠部署等更安全的發布策略。它甚至能夠識別出哪些程式碼變更類型最容易引發問題，從而建議針對性的預防措施。
第四個領域是應用程式韌性提升。
AWS DevOps Agent 會分析應用程式在面對各種故障情境時的表現，建議實施重試機制、斷路器模式、或優雅降級策略。例如，如果它發現某個 API 呼叫經常因為超時而失敗，就會建議實施更合理的超時設置和重試邏輯，或者在第三方服務不可用時提供備用方案。
這種從反應式到主動式的轉變，對澳洲聯邦銀行這樣服務 17,000,000 名客戶的金融機構來說意義重大。正如該銀行雲端服務主管 Jason Sandery 所說：「
AWS DevOps Agent 的思考和行動方式就像經驗豐富的 DevOps 工程師，幫助我們的工程師建立更快速、更具韌性的銀行基礎設施，旨在為客戶提供更好的體驗。這不僅僅是關於更快的解決時間——而是關於維護客戶對我們的信任。」
透過持續學習和改進，
AWS DevOps Agent 幫助團隊累積運維知識，將個人經驗轉化為團隊資產。即使資深工程師離職或休假，他們的故障排查經驗和最佳實踐也能夠透過
AWS DevOps Agent 的建議傳承下來，確保團隊的運維能力不會因為人員變動而受到影響。
跨雲端、混合環境的統一運維體驗
現代企業的 IT 基礎設施很少是單一雲端供應商的純淨環境。更常見的情況是，組織同時使用 AWS、其他公有雲服務、以及本地資料中心的混合架構——有些遺留系統仍在實體伺服器上運行，有些新應用已經容器化並部署到 Kubernetes 叢集，還有些工作負載正在逐步遷移到雲端。這種多樣化的環境為運維團隊帶來巨大挑戰：不同平台有不同的監控工具、不同的日誌格式、不同的存取控制機制，工程師需要掌握多套技能才能有效管理整個系統。
AWS DevOps Agent 的設計從一開始就考慮到這種現實需求，因此它不僅支援 AWS 原生服務，也能夠跨 AWS、多雲和混合環境運作。這意味著無論你的應用程式架構多麼複雜——部分組件在 AWS 上、部分在其他雲端、部分在本地資料中心——AWS DevOps Agent 都能夠提供統一的運維視角和一致的根因分析能力。
這種跨環境的統一體驗是透過廣泛的工具整合實現的。
AWS DevOps Agent 能夠連接到各種可觀測性平台，包括 AWS 原生的
Amazon CloudWatch，以及第三方工具如 Dynatrace、Datadog、New Relic 和 Splunk。這些工具各有特色——Dynatrace 擅長應用程式效能監控、Datadog 提供強大的日誌分析、New Relic 專注於使用者體驗追蹤、Splunk 則在安全事件分析方面表現出色。
AWS DevOps Agent 能夠同時從這些來源提取數據，並在統一的分析框架下關聯它們，避免工程師需要在多個工具之間來回切換。
除了監控工具，
AWS DevOps Agent 還能夠整合 runbooks、代碼庫和 CI/CD 管道。Runbooks 是團隊累積的故障排查手冊，記錄了各種常見問題的診斷步驟和解決方法。
AWS DevOps Agent 能夠閱讀和理解這些 runbooks，並在遇到類似問題時自動應用相關的排查邏輯。代碼庫的整合使得
AWS DevOps Agent 能夠追蹤程式碼變更歷史，將特定的提交與系統行為變化關聯起來。CI/CD 管道的整合則讓它能夠了解部署流程，識別哪些發布可能引入了新的問題。
這種全方位的整合對於像澳洲聯邦銀行這樣管理 1,700 個 AWS 帳戶的組織特別重要。在如此大規模的環境中，單一故障可能涉及多個帳戶、多個區域、多個服務的交互作用。傳統的故障排查方法需要工程師手動查詢每個帳戶的日誌、檢查每個區域的配置、驗證每個服務的狀態——這個過程既耗時又容易遺漏關鍵資訊。
AWS DevOps Agent 則能夠自動執行這些檢查，並將結果以結構化的方式呈現，大幅減少人工操作的時間和錯誤。
更重要的是，
AWS DevOps Agent 能夠幫助組織縮短平均修復時間 (Mean Time To Resolution, MTTR)。MTTR 是衡量運維效率的關鍵指標，代表從發現問題到完全解決問題所需的平均時間。傳統方法下，MTTR 往往受限於人工排查的速度和經驗的深淺。資深工程師可能幾小時就能解決的問題，初級工程師可能需要數天才能搞清楚。
AWS DevOps Agent 提供的快速根因定位和修復建議，能夠讓任何經驗等級的工程師都能在相對短的時間內解決問題,從而大幅降低整體 MTTR，提高系統可用性。
Commonwealth Bank 的實戰反饋：「像經驗豐富的 DevOps 工程師」
當澳洲聯邦銀行雲端服務主管 Jason Sandery 評價
AWS DevOps Agent 時，他使用了一個極具份量的比喻：「
AWS DevOps Agent 的思考和行動方式就像經驗豐富的 DevOps 工程師。」這個評價之所以重要，是因為它來自一個管理著澳洲最大銀行之一雲端基礎設施的資深主管——他見過各種運維工具和解決方案，深知什麼才是真正能夠解決問題的技術。
Sandery 進一步解釋道：「它幫助我們的工程師建立更快速、更具韌性的銀行基礎設施，旨在為客戶提供更好的體驗。這不僅僅是關於更快的解決時間——而是關於維護客戶對我們的信任。」這段話揭示了
AWS DevOps Agent 對金融機構的真正價值：它不只是一個技術工具，而是維護客戶信任的基礎設施保障。
對於服務 17,000,000 名客戶的澳洲聯邦銀行而言，任何一次系統中斷都可能影響數百萬人的日常金融活動——無法轉帳、無法查詢餘額、無法完成交易。這種服務中斷不僅造成直接的業務損失，更會侵蝕客戶對銀行的信任。在這樣的背景下，快速恢復服務的能力就不僅僅是技術問題,更是商業競爭力和品牌形象的核心要素。
Commonwealth Bank 在建置下一代內部雲端平台時,選擇用一個真實的複雜問題來測試
AWS DevOps Agent，這本身就說明了他們對這項技術的重視程度。這個網路和身份管理問題是他們在生產環境中實際遇到過的難題——過去曾讓資深工程師花費數小時才找到根源。當
AWS DevOps Agent 在 15 分鐘內就準確定位問題時，這不是在理想化的實驗室環境中的演示，而是在真實系統複雜度下的實戰驗證。
從技術角度來看，網路和身份管理問題屬於最難排查的故障類型之一。它們通常不會產生明確的錯誤訊息，而是表現為「配置看起來正確但就是不工作」的神秘症狀。這類問題需要工程師同時理解網路拓撲、安全群組規則、IAM 政策、跨帳戶信任關係等多個層面的配置，並在腦海中建構它們的交互作用。即使是經驗豐富的工程師，也需要系統性地排查每一個可能的環節，才能最終鎖定問題所在。
AWS DevOps Agent 之所以能夠如此快速地解決這個問題，是因為它能夠同時處理所有這些層面的資訊，並運用機器學習演算法找出異常模式。它不需要像人類那樣逐一假設和驗證，而是能夠並行分析所有可能性，並根據數據證據快速收斂到正確答案。這種能力對於像澳洲聯邦銀行這樣需要管理 1,700 個 AWS 帳戶、數千名工程師協作的大型組織來說，意義非凡。
更深層的影響在於，
AWS DevOps Agent 幫助澳洲聯邦銀行建立了更具韌性的基礎設施。「韌性」不僅僅指系統能夠在故障發生時快速恢復，更指它能夠從每次故障中學習，逐步減少同類問題再次發生的可能性。透過持續分析歷史事件和提供改進建議，
AWS DevOps Agent 幫助團隊不斷優化系統架構、增強監控覆蓋、改進部署流程，最終達到「主動預防勝於被動應對」的運維境界。
AWS 前沿代理的運維革命：從輔助到自主
AWS DevOps Agent 是 AWS 發布的三個「前沿代理」 (Frontier Agents) 之一，這個命名本身就透露了 AWS 對 AI 代理未來發展方向的願景。所謂「前沿代理」，是指具備三大定義性特徵的新一代 AI 系統：自主性 (Autonomous)、可擴展性 (Scalable) 以及獨立工作能力 (Independent Operation)。
自主性意味著你只需要為代理設定目標，它就能自行找出達成目標的方法。傳統的 AI 工具需要人類詳細指導每一個步驟——「先做 A、再做 B、如果遇到 C 就做 D」——而前沿代理則能夠自己規劃執行路徑。以
AWS DevOps Agent 為例，當系統出現故障時，你不需要告訴它「先檢查日誌、再查看監控指標、然後驗證配置」，它會根據問題的症狀自動決定最佳的調查順序和方法。
可擴展性指的是前沿代理能夠同時執行多個任務，並在多個代理之間分配工作。在大型企業環境中，可能同時發生多起獨立的系統問題，傳統方法需要人工分派不同的工程師去處理不同的問題。
AWS DevOps Agent 則可以部署多個執行個體，每個都能獨立處理一個問題，而不會互相干擾或競爭資源。更進一步，當單一問題足夠複雜時，多個代理還能協同工作——一個負責分析網路層、一個負責檢查應用程式層、一個負責驗證資料庫狀態——然後整合各自的發現得出完整結論。
獨立工作能力是前沿代理與傳統 AI 助手最大的區別。傳統 AI 工具需要持續的人類監督和頻繁的互動確認，但前沿代理能夠在數小時甚至數天的時間跨度內獨立運作,不需要人類持續介入。對運維場景來說,這意味著
AWS DevOps Agent 可以在凌晨 3 點系統出現問題時自動啟動調查，無需喚醒待命工程師。它會收集所有相關資訊、進行根因分析、甚至嘗試自動修復 (如果配置允許的話)，然後在早上將完整的調查報告和建議方案提交給工程師審查。
這三個特徵結合起來，使得前沿代理能夠「像團隊成員一樣工作」而非「像工具一樣被使用」。這種範式轉變對軟體開發生命週期的影響是全方位的。除了運維領域的
AWS DevOps Agent，AWS 同時發布的還有
Kiro autonomous agent (專注於軟體開發) 和
AWS Security Agent (專注於應用程式安全)。這三個前沿代理涵蓋了從程式碼編寫、安全審查到系統運維的完整流程，共同構成了 AWS 對「AI 增強型軟體開發團隊」的完整藍圖。
Kiro autonomous agent 能夠獨立處理程式碼編寫任務——從理解需求、設計解決方案、撰寫程式碼、到提交拉取請求 (Pull Request) ——讓開發者可以專注於更高階的系統設計和業務邏輯。AWS Security Agent 則從設計階段就開始審查安全性，在程式碼審查時掃描潛在漏洞，甚至能夠執行自動化滲透測試，確保應用程式在上線前就已經具備足夠的安全防護。當這三個前沿代理協同工作時，它們能夠覆蓋軟體開發生命週期的所有關鍵環節，大幅提升整體效率和品質。
對於像澳洲聯邦銀行這樣的大型組織而言，前沿代理帶來的價值不僅是個別任務的加速，更是整體工作模式的轉變。工程師不再需要花費大量時間在重複性的故障排查、程式碼審查和安全檢測上，而是可以將精力投入到真正需要人類創造力和判斷力的工作——系統架構設計、業務邏輯優化、客戶體驗改善。這種轉變最終會反映在產品品質和市場競爭力上：更快的功能交付、更穩定的服務品質、更安全的系統架構，以及更高的客戶滿意度。
展望未來，隨著前沿代理技術的持續演進，我們可以預見更多專門化的代理將陸續推出，覆蓋軟體工程的更多領域——測試自動化、效能優化、成本管理、合規檢查等等。這些代理不會取代人類工程師，而是讓他們能夠「站在巨人的肩膀上」，將 AI 的計算能力和人類的創造力完美結合，共同推動技術創新的邊界。
準備好讓 AI 代理成為你的「7×24 待命工程師」了嗎？
從澳洲聯邦銀行在 15 分鐘內解決複雜網路身份管理問題的案例，到 Amazon 內部數千次升級中 86% 的根因識別準確率，
AWS DevOps Agent 已經證明它不僅僅是一個實驗性的技術演示，而是能夠在真實生產環境中創造實際價值的成熟解決方案。當你的團隊不再需要在凌晨被故障告警喚醒、不再需要花費數小時追查神秘的系統異常、不再需要在反應式救火和主動式創新之間艱難選擇時，你就能真正理解「前沿代理」帶來的運維革命意義。
想了解如何在你的組織中部署
AWS DevOps Agent，或探索前沿代理如何轉型你的軟體開發生命週期？
立即聯絡 AWS 台灣團隊，讓我們的解決方案架構師為你規劃最適合的 AI 增強型運維策略。
無法去拉斯維加斯親自體驗？歡迎報名參與Best of AWS re:Invent (AWS 雲端科技發表會) 線上參與，一樣精彩！
https://go.aws/48uR2Tx參考資料：
